AWS再入門2018 リザーブドインスタンス編
こんにちは。池田です。先日、自分の中の勢いに乗ってIbanezのベースを買ってしまいました。ラジコン購入計画は遠のきましたが、高校生の頃に挫折したスラップ奏法に再挑戦しています。
はじめに
今回は知ってるようでちょっと自信がないリザーブドインスタンス（RI）について整理してみました。 ただ、RI全体を対象とするとかなりのボリュームになりますので、EC2のRIに関する基本事項に留めてありますことをご了承ください。
もくじ
インスタンスのファミリーとサイズ、タイプ
RIに限った話ではありませんが、インスタンスファミリーとインスタンスサイズ、インスタンスタイプについて整理しておきます。 ここでは、例として c4.large EC2インスタンスを取り上げます。
- インスタンスファミリーとは
- 「c4」で表されている、ストレージやCPU容量に基づき分類されたもの
- 数字は世代を表している（大きい方が新しい）
- インスタンスサイズとは
- 「large」 で表されている、vCPUやメモリなどのスペックを示したもの
- 他に「medium」や「xlarge」「2xlarge」「4xlarge」などと表される
- インスタンスタイプとは
- ユースケースごとに最適化された組み合わせを識別するためのもの
- インスタンスタイプの種類と、各タイプに分類される現行世代のEC2インスタンスファミリー（2018年3月現在、東京リージョンでRI購入可能なもの）は以下
- 汎用タイプ： t2およびm4
- コンピューティング最適化： c4
- メモリ最適化: x1e、x1、r4
- 高速コンピューティング: P系（p3、p2）およびg3
- ストレージ最適化: i3、d2
※ インスタンスの世代についてはこちらの公式ドキュメントをご覧ください。
インスタンスの正規化係数
インスタンスサイズには正規化係数というものがあります。これはsmallサイズを1として、各インスタンスサイズごとに以下のように数値が定められています。
| インスタンスサイズ | 正規化係数 |
|---|---|
| nano | 0.25 |
| micro | 0.5 |
| small | 1 |
| medium | 2 |
| large | 4 |
| xlarge | 8 |
| 2xlarge | 16 |
| 4xlarge | 32 |
| 8xlarge | 64 |
| 9xlarge | 72 |
| 10xlarge | 80 |
| 12xlarge | 96 |
| 16xlarge | 128 |
| 18xlarge | 144 |
| 24xlarge | 192 |
| 32xlarge | 256 |
この正規化係数は次のような場面で利用されます。
RIの適用対象を選定する自動処理
仮に正規化係数が4であるc4.largeのRIを2つ購入（c4ファミリーの正規化係数を8所有）しているが、オンデマンドで稼働しているc4.largeインスタンスは1つしかなく、c4.mediumが2つオンデマンドで稼働しているとします。 この時、ひとつのRIはそのままc4.largeに適用され、もうひとつのRIは2つのc4.mediumに適用（正規化係数2x2=4）されます。 このように、インスタンスファミリーごとに所有している正規化係数が分配（または合算）され、できる限り所有しているRIが無駄にならないよう自動的に処理される仕組みが提供されています。 （※ 2018年3月現在、Linux/UNIXインスタンスに限ります）
文章だと少しわかりにくいので図にすると以下のようなイメージです。
これを「インスタンスサイズの柔軟性」と呼びます。
このインスタンスサイズの柔軟性により、購入済みのRIが効率的に適用され、コスト削減の一助となるよう設計されています。
（※ 2018年3月現在、インスタンスサイズの柔軟性はリージョンの共有テナンシーで購入されたLinux/UNIX RIが対象です）
RI購入計画
RIは1年または3年という、インスタンスの長期利用予約をすることでオンデマンド料金から大幅な割引を受けられる仕組みですので、その期間以上、常時稼働させることが明らかな場合は特に気にする必要はありませんが、インスタンスファミリーやサイズの変更が発生した場合、適用対象外となってしまう可能性があります。 そのため、サービスの運用計画と以下の点を照らし合わせて購入するRIを選定する必要があると考えます。
- サービスは1年以上継続予定のものか
- リソースは1年間、現状維持でも不足しないか
- スケールアップ、スケールアウトの計画はないか
- インスタンスの稼働計画と購入を想定しているRIの削減率（損益分岐点）を確認したか
- キャパシティ予約を目的とするか否か
- キャパシティの予約を目的とする場合はアベイラビリティゾーン（AZ）を指定して購入する必要があります
などなど、RIの購入に先立ち、サービスの計画以外にも、既存インスタンスの負荷や利用者の推移といった部分も含め、リソースの見直し、中長期計画の再確認も実施しておく方が良いと思います。
購入済みRIのインスタンスサイズ変更
Amazon Linuxに限られますが、インスタンスサイズの柔軟性と同様の考え方で、インスタンスサイズの変更が行えます。 この変更が必要な場面としては以下のようなケースが想定されます。
- 同じファミリー内で、インスタンスサイズを大きくしたい（スケールアップする）場合
- c4.largeインスタンスをc4.xlargeやそれ以上にする場合、所有している複数のc4.large RIを必要な正規化係数になる数量（c4.xlargeとしたいなら2つ）を結合することにより、変更が可能となります
- 同じファミリー内で、インスタンスサイズを小さくしたい（スケールダウンする）場合
- c4.2xlargeインスタンスをc4.largeインスタンスに変更する場合、所有しているc4.2xlarge RIを分割することで、c4.largeインスタンス4台に割り当てることが可能となります
RIを購入するメリット
1年以上インスタンスを起動させる場面においてRIによる割引は大きなメリットとなります。 長期間（1年または3年）の利用を予約することで、同期間に発生するオンデマンド料金よりも安く利用できる定期券のようなものです。ただし、購入後のキャンセルは行えませんので注意が必要です。 ですので、先にご紹介したように購入の前に中長期計画の確認や利用するリソースなどを見直しておく必要があります。 EC2インスタンスのオンデマンド料金とRIの比較は以前の記事をご参照いただければと思います。
RIを購入するための準備
ここまでにご紹介した諸々の確認が済んで、コスト削減が見込めるとなれば、さっそく購入の準備に取り掛かりましょう。 EC2のRIを購入するには以下の情報を事前に整理しておくことをお勧めします。
- 既存インスタンスの一覧
- これはリソースの見直しなどを行った際に、既に用意されていると思われますが、一応あると良いでしょう。
- 購入したいRIの一覧
- OS種別
- インスタンスファミリーとサイズ
- AZ指定かリージョン指定か
- スタンダードRI（購入時に指定したインスタンスタイプより大きなものへの「変更」はできないが「結合」は可能）とするか、コンバーティブルRI（差額費用の支払いをすることで、「インスタンスタイプの変更」や、より大きなインスタンスサイズへの「変更」ができるもの）とするか（両者の違いについては昨年11月の投稿をご参照ください。）
- 購入期間をどうするか（1年または3年）
- 支払い方法はどうするか（全前払い、一部前払い、前払いなし）
- テナンシー（共有ハードウェアか専用ハードウェアか）
- それぞれ購入する数量
- 「1ヶ月間でのRI購入上限値」という制限があり、デフォルトでは20となっています。制限値以上のEC2 RIを購入する場合は事前に「上限緩和申請」を行う必要があり、通常数日を要しますので注意が必要です。現在の上限値はEC2ダッシュボードの「制限」メニューから確認することができます。
- 合計購入金額と内訳
- 購入するタイミングは適切か
- 1年または3年後の同じ日に再び購入する可能性が高いわけですから、長期休暇やご自身の大切なイベントと重なるタイミングは避けておくのが幸せかもしれません。
- 誰が購入操作を実施するか
- インスタンスによっては1年全前払いの金額が$10,000を超えるものも多くあります。また、キャンセルはできませんので、購入操作は慎重に行う必要があります。できるだけ、同僚や上司にダブルチェックをしてもらえるよう手配しておきましょう。
まとめ
では実際に購入してみましょう！と続けたかったのですが、予定よりも長くなってきましたので今回はここまでのご紹介とし、購入操作編は次回とさせていただきます。購入操作編の公開までに、ぜひご利用中のリソースとそのコストなどをチェックしておいてください。 ここまで読んでいただき「お得なことや事前準備はわかったけれど、自分でRI購入操作をするのは敷居が高い！」と感じた方は、どうぞクラスメソッド メンバーズフルサポートプランをご検討ください。
